-
-
Notifications
You must be signed in to change notification settings - Fork 475
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: add governance #288
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍 Thank you for spending much time on thinking the governance model!
It might be okay to add this later, but it would be good to have an example of what specific contributions should be made in order to be in a certain role. I haven't seen that in many other repositories though. |
Co-authored-by: Daiki Nishikawa <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey! I've worked in Node.js, Electron, and the OpenJS Foundation for a number of years on various Governance tasks. I'm excited and hopeful for biome, and wanted to take this opportunity to communicate some of the lessons I've learned over the years in hopes it'll be helpful for y'all, accelerate the project's maturity, and help you avoid some pain.
No worries if you don't take any of the advice or suggestions, but did just want to put them out there for you.
GOVERNANCE.md
Outdated
|
||
Leads are the owners of the organisation. | ||
|
||
Leads have additional privileges over core contributors. Leads control and maintain sensitive project assets and act as tiebreakers in the event of disagreements. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
act as tiebreakers
if they are acting as tiebreakers, you'll likely want to either ensure that one lead is a tiebreaker, or that there will otherwise always be a way to ensure a decision rather than a stalemate (50/50).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An odd number of leaders could avoid the issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated the document, only one lead should step up and make the decision.
@Conaclos that wouldn't work. Being a lead is essentially being a core contributor with more burden (conflict resolution rights, holding sensitive info/assets). We can't force people to join only because we require an odd number.
GOVERNANCE.md
Outdated
|
||
### Inactivity | ||
|
||
There are no expectations around activity once someone becomes a core contributor or maintainer. Inactive core contributors or maintainers may have voting rights removed; however, will always retain their status. A core contributor or maintainer may request their voting rights back upon sufficient activity. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One of the hardest lessons I learned from the io.js Governance Structure that ended up as the Node.js Governance Structure was that the decision to never remove inactive members was perhaps one of the biggest barriers to progress. Eventually, we introduced an emeritus system that IMO has been extremely helpful in distinguishing who is an active contributor vs. who once was but is not longer active.
The Emeritus system also helps ensure a more secure environment, since inactive accounts don't have push permissions, while still allowing for recognition and an easy way to start working again (simply ask to be re-added to the project from emeritus status, and you will be).
To be in good conscience, I feel obligated to at least leave a comment urging you to consider a way to build-in a system to step-down or off-board people who are inactive after having worked in such a system without an escape hatch like Emeritus for so long.
GOVERNANCE.md
Outdated
|
||
## Current Members | ||
|
||
Members are listed in alphabetical order. Members are free to use the full name, GitHub handle, or any other nickname they wish to be addressed. Members are free to disclose their gender. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a non-binary person, I appreciate the last part here, but generally disclosing gender isn't something I'd expect to be done. My guess is that you meant pronouns and used gender as a proxy for that, so here's two suggestions on how to tweak this:
Members are listed in alphabetical order. Members are free to use the full name, GitHub handle, or any other nickname they wish to be addressed. Members are free to disclose their gender. | |
Members are listed in alphabetical order. Members are free to use the full name, GitHub handle, or any other nickname they wish to be addressed. Members are free to disclose their gender and pronouns. |
Members are listed in alphabetical order. Members are free to use the full name, GitHub handle, or any other nickname they wish to be addressed. Members are free to disclose their gender. | |
Members are listed in alphabetical order. Members are free to use the full name, GitHub handle, or any other nickname they wish to be addressed. Members are free to disclose their pronouns. |
GOVERNANCE.md
Outdated
### Lead team | ||
|
||
- [Emanuele Stoppa @ematipico](https://github.com/ematipico) | ||
|
||
### Core Contributors team | ||
|
||
|
||
### Maintainers team | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would strongly recommend keeping these documented in a different place. Governance is usually more of a static document, and parts that are going to be changing with frequency are often better kept elsewhere both to make them easier to change and to allow easier historical parsing of a Governance doc. Going through 50 membership changes to find a specific language change is often less than ideal.
Co-authored-by: Tierney Cyren <[email protected]>
I added a paragraph: https://github.com/biomejs/biome/blob/chore/governance/GOVERNANCE.md#contributions |
Thank you @bnb ! I reviewed your comments and made the suggested changes. About the "off-boarding" system, what do you recommend? Any word of advice? I rephrased the paragraph, but I am not sure I am on the right track. @denbezrukov @unvalley since you had questions, I dismissed your approval and requested a review again. I would prefer to have all the questions answered first. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for update!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left some comments.
We could also add a diagram to highlight roles and how one is promoted to another. However, this is an enhancement we can do later.
Co-authored-by: unvalley <[email protected]>
04e86be
to
1e66735
Compare
Summary
A first draft of the governance. All @biomejs/core-contributors must approve this PR before being merged.
Test Plan
Review it and approve it